[Impeller] add GLES renderpass that avoids command encoding. #57077
Conversation
| const TextureAndSampler bound_textures[], | ||
| const BufferResource bound_buffers[], |
There was a problem hiding this comment.
Why are you converting these to c arrays? It looks like everything going into this is a vector anways.
There was a problem hiding this comment.
I'm using a fixed size std::array in render_pass_gles3.
There was a problem hiding this comment.
Missed that, thanks. We'll be able to use std::span in c++20.
There was a problem hiding this comment.
god I'm so ready for span
| Range range = dirty_range_.value(); | ||
| if (gl.MapBufferRange.IsAvailable()) { | ||
| void* data = | ||
| gl.MapBufferRange(target_type, range.offset, range.length, |
There was a problem hiding this comment.
So at least locally for me, this is the trick that is letting us incrementally write to the device buffers like we do for vulkan/metal. I believe this will be faster but it likely needs a run through the devicelab to confirm.
|
After more investigation today, I'm going to close this as infeasible. glMapBufferRange does not give us access to persistently mapped buffers, which is the missing piece to make this fast. That is only available via an extension in GLES 3.1+. At that point, just use vulkan. Without persistently mapped buffers, we need to constantly map/unmap which is fairly expensive. |
2 participants
Need to do some refactoring to share more logic, but the rough outline of avoiding impeller::Command altogether, like we do for Vulkan and Metal.
For each recorded command, we temporarily store a fixed number of bindings, then immediately encode when draw is called. Unlike Metal/Vulkan, we cannot simulatenous record to multiple render passes, but the way the 2d renderer works this isn't a problem. The recording of render pass always forms a simple stack, so we can save/restore the previous sets of framebuffer bindings at the beginning and end of the pass.